Important: Some of the features may not be available in this release. Kindly contact your local Cisco representative for more information on supported features.IPCF acts as a PCRF functions supplemented with usage monitoring capability that enables policies around data consumption. IPCF interfaces with the PCEF over standard Gx/Gxa/Rx interface for policy management and optionally Volume Reporting over standard Gx (VRoGx) interface for getting the usage of IP Connectivity Access Network (IP-CAN) sessions.
|
•
|
|
•
|
|
•
|
The SSC interacts with IPCF over Sp (a standard Sh protocol based) interface for given functionality. SSC also supports a proprietary EN interface, which is based on XML-RPC protocol, to receive event notification data from IPCF.
For more information on SSC function and supported interfaces, refer Subscriber Service Controller Installation and Administration Guide.
For more information on PPT function and supported interfaces, refer Policy Provisioning Tool Installation and Administration Guide.
|
•
|
|
•
|
Cisco PID [ ASR5K-00-PC10SL ] IPCF Session License, 10k Active Sessions, or Starent Part Number [ 600-20-0107 ] IPCF Session License, 10k Active Sessions.
|
|
•
|
Cisco PID [ LIF5K-00-PC10SL ] IPCF Session License, 10K Active Sessions (Failover), or Starent Part Number [ 600-21-0107 ] Integrated Policy Control Function R3, 10K Sessions (Failover).
|
|
•
|
|
•
|
System Management Cards (SMC): Provides full system control and management of all cards within the ASR 5000 platform. Up to two SMC can be installed; one active, one redundant.
|
|
•
|
Packet Services Cards (PSC/PSC2): Within the ASR 5000 platform, PSCs/PSC2s provide high-speed, multi-threaded bearer context processing capabilities for IP services. Up to 14 PSCs/PSC2s can be installed, allowing for multiple active and/or redundant cards.
|
|
•
|
Switch Processor Input/Outputs (SPIOs): Installed in the upper-rear chassis slots directly behind the SPCs/SMCs, SPIOs provide connectivity for local and remote management, central office (CO) alarms. Up to two SPIOs can be installed; one active, one redundant.
|
|
•
|
Line Cards: The following rear-loaded line cards are currently supported by the system:
|
|
•
|
Ethernet 10/100 and/or Ethernet 1000 Line Cards: Installed directly behind PSCs, these cards provide the physical interfaces to elements in the UTRAN/E-UTRAN/cdma2000-1x/HRPD network. Up to 26 line cards should be installed for a fully loaded system with 13 active PSCs/PSC2, 13 in the upper-rear slots and 13 in the lower-rear slots for redundancy. Redundant PSCs/PSC2s do not require line cards.
|
|
•
|
Quad Gig-E Line Cards (QGLCs): The 4-port Gigabit Ethernet line card is used in the ASR 5000 system only and is commonly referred to as the Quad-GigE Line Card or the QGLC. The QGLC is installed directly behind its associated PSC/PSC2 to provide network connectivity to the packet data network.
|
|
•
|
10 Gig-E Line Cards (XGLCs): The 10 Gigabit Ethernet Line Card is used in the ASR 5000 system only and is commonly referred to as the XGLC. The XGLC supports higher speed connections to packet core equipment, increases effective throughput between the ASR 5000 and the packet core network, and reduces the number of physical ports needed on the ASR 5000.
|
|
•
|
Redundancy Crossbar Cards (RCCs): Installed in the lower-rear chassis slots directly behind the SPCs/SMCs, RCCs utilize 5 Gbps serial links to ensure connectivity between Ethernet 10/100/Ethernet 1000/Quad-Gig-E/10-Gig-E line cards and every PSC/PSC2 in the system for redundancy. Two RCCs can be installed to provide redundancy for all line cards and PSCs/PSC2.
|
Important: Additional information pertaining to each of the application and line cards required to support IPCF function is located in the Hardware Platform Overview chapter of the Product Overview Guide and for other PCC elements refer respective Installation and Administration Guides.In standalone deployment multiple PCEF (GGSN/PDSN/P-GW) connects to a single IPCF through Gx interface and served by the PCC elements through IPCF.
In co-located deployment IPCF sits with PCEF on the same chassis. It interacts with PCEF through internal connection matching Gx reference and connects to other PCC elements over various interfaces.
|
•
|
Gx: This reference is an interface between IPCF and PCEF. It is a Diameter protocol-based interface over which the IPCF communicates with a PCEF for the provisioning of charging rules. The charging rules are based on the dynamic analysis of flows used for a 3GPP or Non-3GPP IP-CAN subscriber session.
|
The Gx reference point enables an IPCF to have dynamic control over the policy and charging control behavior at a PCEF. The Gx reference supports the following functions:
|
•
|
Termination of Gx session (corresponding to an IP-CAN session) by PCEF or IPCF
|
Important: The IPCF decision to termination an Gx session is based on situation like removal of a UE subscription etc.One or more Gx interfaces can be configured per system context.
To provide accessibility to PDSN as PCEF in CDMA/HRPD access network for 3GPP IP-CAN type session, Gx interface uses NAI and IMSI as subscriber Id and ESN and MEID for user equipment information.
|
•
|
Gxa: This reference is an interface between IPCF and the Bearer Binding and Event Reporting Function (BBERF) at AN-GW. It is a Diameter protocol-based interface and enables an IPCF to have dynamic control over the BBERF behavior at AN-GW.
|
The Gxa reference point enables the signalling of QoS control decisions and it supports the following functions:
|
•
|
One or more Gxa interfaces can be configured per system context.
|
•
|
Sp: This is a Diameter-based interface resides between Cisco IPCF and SSC. It is based on standard Sh interface.
|
Only 1 Sp interface can be configured per system context.
|
•
|
Event Notification Interface (EN): The EN interface supports uni-directional transfer of events from IPCF to SSC. This is an XML-RPC protocol based proprietary interface to send outbound event notifications to the SSC and forward these events to an event application module to generate mail/SMS notification to user/subscriber.
|
Only 1 EN interfaces can be configured per system context.
|
•
|
Rx: This interface is the reference point between the Application Function (AF); i.e. IMS and the IPCF. This is a Diameter based interface.
|
The Rx reference point enables transport of application level session information from AF to IPCF. Such information includes:
One or more Rx interfaces can be configured per system context.
|
•
|
CORBA-based Interface: IPCF supports the North-bound CORBA interface support for PPT and WEM management applications that can easily be integrated, using standards-based protocols (CORBA and SNMPv1, v2), into higher-level management systems. It gives the ability to operator to integrate the system into their overall network, service, and business management systems. In addition, all management is performed out-of-band for security and to maintain system performance.
|
|
•
|
|
•
|
|
•
|
|
•
|
|
•
|
|
•
|
Important: System management functionality is enabled for console-based access by default. For GUI-based management support, refer Web Element Management System.
Important: For more information on command line interface based management, refer Command Line Interface Reference.|
•
|
System: Provides system-level statistics
|
|
•
|
Card: Provides card-level statistics
|
|
•
|
Port: Provides port-level statistics
|
|
•
|
PCC-AF: Provides PCC Application Function related statistics
|
|
•
|
PCC-Policy: Provides PCC Policy related statistics
|
|
•
|
PCC-Service: Provides statistics collected for PCC service on a chassis endpoint in PCC service
|
|
•
|
PCC-Sp-Endpoint: Provides statistics collected at Sp interface endpoint in PCC service
|
|
•
|
Alert: A value is monitored and an alert condition occurs when the value reaches or exceeds the configured high threshold within the specified polling interval. The alert is generated then generated and/or sent at the end of the polling interval.
|
|
•
|
Alarm: Both high and low threshold are defined for a value. An alarm condition occurs when the value reaches or exceeds the configured high threshold within the specified polling interval. The alert is generated then generated and/or sent at the end of the polling interval.
|
|
•
|
SNMP traps: SNMP traps have been created that indicate the condition (high threshold crossing and/or clear) of each of the monitored values.
|
|
•
|
Logs: The system provides a facility called threshold for which active and event logs can be generated. As with other system facilities, logs are generated Log messages pertaining to the condition of a monitored value are generated with a severity level of WARNING.
|
|
•
|
Alarm System: High threshold alarms generated within the specified polling interval are considered “outstanding” until a the condition no longer exists or a condition clear alarm is generated. “Outstanding” alarms are reported to the system's alarm subsystem and are viewable through the Alarm Management menu in the Web Element Manager.
|
Important: For more information on threshold crossing alert configuration, refer Thresholding Configuration Guide.
Important: Some of the following features may require the purchase of an additional license to implement the functionality with the IPCF node.|
•
|
Task recovery mode: Wherein one or more session manager failures occur and are recovered without the need to use resources on a standby packet processing card. In this mode, recovery is performed by using the mirrored “standby-mode” session manager task(s) running on active packet processing cards. The “standby-mode” task is renamed, made active, and is then populated using information from other tasks such as AAA manager.
|
|
•
|
Full packet processing card recovery mode: Used when a packet processing card hardware failure occurs, or when a packet processing card migration failure happens. In this mode, the standby packet processing card is made active and the “standby-mode” session manager and AAA manager tasks on the newly activated packet processing card perform session recovery.
|
Important: For more information on this feature, refer Session Recovery chapter in System Administration Guide.
Important: For more information on WEM support, refer WEM Installation and Administration Guide.Every time a new IP-CAN session is established through PCEF’s Gx interaction with IPCF, it queries SSC specifically to get subscriber’s profile as well as the usage details during the current billing cycle. After receiving the subscriber profile, it forward the same to PCEF. For remaining duration of the session the subscriber policy profile remains cached with IPCF and no query performed over Sp.
Moreover, on any changes to the profile or to the subscription plan, SSC notifies IPCF over Sp interface, that is managing the session for the subscriber getting affected. IPCF ensures that the local repository has the most updated profile record for the subscriber at all times.
In the case IPCF is also tracking the usage for deriving policy decision on the basis of same, it would appoint itself for pre-paid usage monitoring through Gx for usage control.
In the case where IPCF also performs usage monitoring via VRoGx interface, in addition to the session state triggers, additionally the usage can be monitored and operator can define various policy triggers around the usage thresholds for a session or even group of sessions. In the cases where usage is to be monitored across multiple sessions and PCEFs (from same or group of subscribers); e.g. for group policies, IPCF combined with SSC’s usage monitor module, enable the PCC system to track and trigger appropriate treatments required for the multiple sessions. IPCF communicates with SSC over Sp interface which enables a synchronous fetch and update related to usage as well as asynchronous notifications from SSC to the IPCF, handling the sessions which may get impacted due to consumption reported by a session being tracked at a different IPCF.
At this stage the PCEF initiates a new Gx session by sending a Diameter CCR to the IPCF and set the CC-Request-Type AVP to INITIAL_REQUEST.
|
•
|
|
•
|
In this procedure the IPCF associates the Gx session for the new IP-CAN session with the corresponding Gateway Control Session and maintains the aligned set of PCC and QoS rules in the PCEF as applicable for the case.
|
4.
|
Optional. If the IPCF needs subscription-related information and does not have it, the IPCF sends a Profile Request to the SSC in order to receive the information.
|
If online charging is applicable then the PCEF requests credit information from the OCS over the Gy interface.
This procedure is applicable for establishment of Rx connection between IPCF and AF (IMS) in core network.
The following figure and the text that follows describe the message flow for an Rx connection establishment procedure.
|
2.
|
|
4.
|
Optional. If the IPCF needs subscription-related information and does not have it, the IPCF sends a Profile Request to the SSC in order to receive the information.
|
|
9.
|
When Gxa does not apply for the IP-CAN session, IP-CAN bearer signalling is executed separately for each IP-CAN bearer under the following conditions:
|
The IPCF complies with the following standards for UTRAN/E-UTRAN/cdma2000-1x/HRPD networks services.
|
•
|
|
•
|
|
•
|
